nice! i think it would be good to have a function to define this limit, like discussed here: #1228 but 1.5s seems to be a good default

Sounds like a good idea to me. Should the function live in the settings.mjs file? What would be the ideal way to make it callable from the repl window?

I'm a bit unsure about this, I think it will surprise people in some cases if it's default on.

The problem could also be solved by one or both of

• trimming the default samples to be more sensible
• a max polyphony option that stops long running notes (or some other scheme)

Saying that I do sometimes wonder what would happen if samples were all clipped to hap duration, like synths. Probably mininotation would have evolved differently to cope/take advantage of that, to make it easier to create overlapping haps.

I'm a bit unsure about this, I think it will surprise people in some cases if it's default on.

The problem could also be solved by one or both of

• trimming the default samples to be more sensible
• a max polyphony option that stops long running notes (or some other scheme)

Saying that I do sometimes wonder what would happen if samples were all clipped to hap duration, like synths. Probably mininotation would have evolved differently to cope/take advantage of that, to make it easier to create overlapping haps.

I would strongly advocate for this solution or "all clipped to hap duration" + using release time to get longer sample lengths. I did a guest lecture for the berklee experimental music program recently where the students had been learning generative music concepts with strudel. Nearly all of them had issues with their projects crashing due to too many buffers going on. I also saw the same thing happen to a girl who was performing this weekend. Trimming the default samples is something that should also be done imo, but this problem also happens for user and imported samples

Yep agreed this is a super important issue to solve.

I would strongly advocate for this solution or "all clipped to hap duration" + using release time to get longer sample lengths.

When you say 'this solution' do you mean this PR or something I mentioned?

I've done quite a lot of workshops and haven't really hit a performance issue, including at recent workshops with school kids who were pushing strudel hard on chromebooks. I am used to doing workshops with dirt samples rather than using the longer piano sounds etc though.

Clipping sounds at a set limit does feel drastic to me, and clipping them at hap duration would change the quality of music a lot.. So I am still in favour of solving this by stopping sounds when a configurable max polyphony is reached, but don't know how tricky that would be to implement in superdough. The classic dirt just stops the longest running sound when it hits the max, as far as I remember.

Yep agreed this is a super important issue to solve.

I would strongly advocate for this solution or "all clipped to hap duration" + using release time to get longer sample lengths.

When you say 'this solution' do you mean this PR or something I mentioned?

I've done quite a lot of workshops and haven't really hit a performance issue, including at recent workshops with school kids who were pushing strudel hard on chromebooks. I am used to doing workshops with dirt samples rather than using the longer piano sounds etc though.

Clipping sounds at a set limit does feel drastic to me, and clipping them at hap duration would change the quality of music a lot.. So I am still in favour of solving this by stopping sounds when a configurable max polyphony is reached, but don't know how tricky that would be to implement in superdough. The classic dirt just stops the longest running sound when it hits the max, as far as I remember.

I was referring to this PR. Unfortunately I have seen this issue happen to multiple performers. I also saw a performer's set glitch out and freeze SXSW this year because of it as well, so I think it would be good if we can solve this sooner than later imo.

Max polyhpony would be a good solution also, though I am also not sure how that could be implemented in superdough

Another idea I had, which might be a more ideal solution, is to add a property for clip value for each sound in the strudel JSON. This way you can specify that your drum samples have a clip of infinity, and everything else has a clip of 1 by default so the clip behavior is consistent with the synth sounds.

I'm not totally against the idea of having clip default to 1 to make sounds consistent with synths. Maybe .clip(-1) or .noclip() could turn it off. It seems a big change tho!

I guess unbound polyphony will always cause freezes - even if sounds are clipped, too many could still be triggered by mistake. I've not looked into superdough code yet..

i think max voice count is the way to go to fix glitches related to too much layering. (like cut, but polyphonic, fifo). not sure if autoclipping by default is best, but surely it would be good to have as an option

I remember a synth where you could set how notes were allocated. It took me a while to find the search term to use - 'note priority' or 'stealing priority', .e.g.:

• Arbitrary: Don't care, the adapter will randomly steal one
• Quietest: The quietest note will go first (this is usually less noticeable when many notes are playing)
• Closest to New: This will steal the note thats the closest to the new note you want to play
• Oldest: Will steal the note that's been playing for the longest period of time
• Newest: Will steal the note that's been playing for the shortest period of time

Monosynths seem to generally use lowest priority.

I think newest priority is probably the best we can do when we don't really know anything about the sounds that are being triggered though.

Maybe it could be nice to have a priority system on top so .priority(-100) would be stopped before any .priority(100) haps.. Comparing priority first then age

I remember a synth where you could set how notes were allocated. It took me a while to find the search term to use - 'note priority' or 'stealing priority', .e.g.:

* Arbitrary: Don't care, the adapter will randomly steal one

* Quietest: The quietest note will go first (this is usually less noticeable when many notes are playing)

* Closest to New: This will steal the note thats the closest to the new note you want to play

* Oldest: Will steal the note that's been playing for the longest period of time

* Newest: Will steal the note that's been playing for the shortest period of time

Monosynths seem to generally use lowest priority.

I think newest priority is probably the best we can do when we don't really know anything about the sounds that are being triggered though.

Maybe it could be nice to have a priority system on top so .priority(-100) would be stopped before any .priority(100) haps.. Comparing priority first then age

thats a good list! id expect oldest to be the default

we now have #1317 , so i wonder how this changes the clip discussion. it might still be desirable to not have samples that are very long build up a ton of overlaps. max polyphony is 128, so 128 overlaps can still happen

I'm still in the "don't do that then" camp, trimming silence off the default samples, rather than trimming them on playback. This would avoid unnecessary bandwidth use and download time of all that unwanted silence/near silence. It also means if people really want super long tails on their samples they can do that without having to remember to turn of automatic clipping.

thats a good list! id expect oldest to be the default

Agreed, confusingly 'oldest' in that list is 'newest priority'

Adding a release time would also make the samples longer, you don’t have to mess with the clip value for that. Currently the voice stealing happens so the longest playing voice gets stolen